home *** CD-ROM | disk | FTP | other *** search
/ The Arsenal Files 1 / The Arsenal Files (Arsenal Computer).ISO / bbs / tm0305.txt < prev    next >
Text File  |  1994-01-23  |  31KB  |  610 lines

  1. SEA Technical Memorandum #0305, Adding GroupMail to a Bink/Confmail System
  2. Contributed by: Jack Decker
  3. Last updated: March 7, 1989
  4. Copyright 1989 by System Enhancement Associates, Inc.
  5.  
  6.  
  7.  
  8.              Adding GroupMail to a Binkleyterm/Confmail System
  9.  
  10.  
  11. This document is an attempt to give you some solid information on how to 
  12. implement GroupMail on a system that is already successfully running 
  13. BinkleyTerm and confmail.  
  14.  
  15. This information is going to be presented more or less in "cookbook" 
  16. format.  I am going to make a few assumptions to start with... that you are 
  17. not a "top star" for any conference, that you're not going to feed 
  18. GroupMail conferences to any non-MSDOS systems that can't run the GroupMail 
  19. software, and that you're not going to try and convert any GroupMail 
  20. conference to Echomail or vise-versa.  If any of these assumptions don't 
  21. apply to you, read on anyway, I'll cover one of the exceptions later, and 
  22. the rest of the information will still be useful to you.  
  23.  
  24. This is NOT a substitute for the GroupMail documentation.  Read it, too!  
  25. Also, please count on this information containing at least one glaring 
  26. error and at least a couple of things that could have been done more easily 
  27. in some other way.  I don't claim to be perfect.  But I would like to know 
  28. of any errors that you do find.  
  29.  
  30. Here are the changes you will need to make to your system: 
  31.  
  32.  1) CONFIG.SYS - Group requires some new environment variables to be set.  
  33.     If you haven't already done so, you can reserve extra space for 
  34.     environment variables by inserting the following line into your 
  35.     CONFIG.SYS file: 
  36.  
  37.          shell=command.com /p /e:512 
  38.  
  39.  2) AUTOEXEC.BAT - Here is where you add a new line to set a new 
  40.     environment variable that will be used by GroupMail: 
  41.  
  42.          SET SEADOG=C:\OPUS 
  43.  
  44. The SEADOG variable should point to the directory that you normally run 
  45. BinkleyTerm from.  
  46.  
  47.  3) BBS.BAT - Your batch file that runs Binkley, ConfMail, etc.  Here are 
  48.     the changes you need to make: 
  49.  
  50.     a) If you test for the existence of mail bundles in your net files area 
  51.        before running ConfMail Import, either delete these tests (you don't 
  52.        really need them anyway) or add tests for the GroupMail bundles you 
  53.        expect to receive.  GroupMail bundles are named with the area name 
  54.        (up to eight characters) plus an unpredictable three-character 
  55.        extension.  So, for example, if you are expecting to receive 
  56.        GroupMail bundles for the COOKING area, you could test for files 
  57.        named COOKING.* (or COOKING.???) in your net files area.  I again 
  58.        emphasize that such tests are normally not necessary, but some 
  59.        people like to use them to shave a few seconds off of batch file 
  60.        processing time.  
  61.  
  62.     b) your line that calls ConfMail Import should *NOT* include the -M 
  63.        option, but *SHOULD* include the -K option.  I use the following 
  64.        line: 
  65.  
  66.             confmail import areas.bbs -K -N -F confmail.out 
  67.  
  68.        Now a bit of explanation... if you really want to use the -M option, 
  69.        you can probably do so as long as you are not converting any 
  70.        GroupMail bundles to echomail prior to passing them downstream.  I 
  71.        suggest removing the -M option now (if you have been using it) 
  72.        because sooner or later you may wish to convert a GroupMail 
  73.        conference to echomail, and it won't work if -M is set.  
  74.  
  75.        The -K option will automatically kill all the null file attach 
  76.        messages that your GroupMail feed generates.  If you don't mind 
  77.        skipping through all the null file attach messages when you read 
  78.        your netmail (you WILL mind eventually), leave out the -K.  
  79.  
  80.     c) You should place the following line immediately AFTER your call to 
  81.        ConfMail Import, BEFORE you do anything else: 
  82.  
  83.             GROUP IN /L 
  84.  
  85.        This does two things... first, it unpacks any GroupMail bundles you 
  86.        may have received, and second, it scans your netmail area for any 
  87.        GroupMail messages that need to be readdressed to your uplink.  That 
  88.        is why it needs to be run AFTER ConfMail Import... if you run it 
  89.        BEFORE ConfMail Import, any messages you've received from your 
  90.        downstream nodes may not get properly forwarded to the Top Star via 
  91.        your GroupMail feeds.  And you need to run Group In BEFORE running 
  92.        ReMapper, oMMM, or any other program that may change the headers of 
  93.        those messages.  So play it safe, and run Group In right AFTER 
  94.        ConfMail Import.  
  95.  
  96.        By the way, the /L tells GROUP to relink the message threads.  It 
  97.        does basically the same thing for GroupMail conferences that 
  98.        ReplyLnk (or ConfMail Maint in older versions of ConfMail) does for 
  99.        your echomail conferences.  
  100.  
  101.     d) Just prior to calling oMMM, you should place the following line: 
  102.  
  103.             GROUP OUT 
  104.  
  105.        This will check all your GroupMail areas for new messages, and send 
  106.        out anything you have waiting.  
  107.  
  108.     Now, if you have read the GroupMail documentation, you may be a little 
  109.     confused at this point, since the docs tell you to run GROUP on certain 
  110.     schedules (GROUP OUT in the evening before your mail hours, and GROUP 
  111.     IN in the morning after all mail has been received).  But keep in mind 
  112.     that the folks writing the documentation are using SEADOG, which runs 
  113.     on schedules.  You probably aren't running schedules in that way.  If 
  114.     by chance you do run ConfMail Import only at certain specified times, 
  115.     just do GROUP IN immediately afterward.  But, if like most of us, you 
  116.     run ConfMail Import every time mail is received, you should run GROUP 
  117.     IN immediately afterward.  If you then do a ConfMail Export, you should 
  118.     run GROUP OUT prior to calling oMMM.  GROUP runs very fast (faster than 
  119.     ConfMail when tossing messages, in my opinion) so you needn't worry 
  120.     about it consuming an inordinate amount of time while executing on your 
  121.     system.  
  122.  
  123.  4) AREAS.BBS - There are two important considerations here.  First, if you 
  124.     are using a BAD_MSGS area, GET RID OF IT NOW!!!!  This is *EXTREMELY* 
  125.     important.  If you don't do this, some or all of the GroupMail messages 
  126.     originating on your system (or on systems that you feed) will be tossed 
  127.     to the BAD_MSGS area by ConfMail, and will never leave your system.  
  128.     Second, make sure you don't have any echo area names that duplicate 
  129.     GroupMail areas, for the same reason (ConfMail will toss any messages 
  130.     that are supposed to go to your uplinks to those areas instead.  The 
  131.     exception to this is if you're converting a GroupMail conference to 
  132.     Echomail, but right now we're assuming you aren't doing that, 
  133.     remember?).  
  134.  
  135.     Of course, someone will say that if you are VERY careful about how you 
  136.     write your batch file, you can get around these problems.  That may be 
  137.     true (although I have my doubts!), but in any event I don't feel like 
  138.     giving a short course in writing batch files here.  I'm simply taking 
  139.     the safe road by saying "don't do these things." 
  140.  
  141.  5) CONFIG.DOG - You need one of these, even though the GroupMail 
  142.     documentation says that a Mail.Sys file will do (it won't, at least not 
  143.     with GroupMail versions through 2.04).  Fortunately, a Config.Dog file 
  144.     is simple to make... you just use any text editor.  Mine looks like 
  145.     this: 
  146.  
  147.          name Jack Decker
  148.          node 1:154/8
  149.          aka 77:1011/8
  150.          aka 8:70/8
  151.          mail C:\MSG\NET
  152.          files C:\FILE\NET
  153.  
  154.     "Name" is the name of the Sysop, "Node" is your primary address, "Aka" 
  155.     lines contain any other addresses you use (in the same net or in other 
  156.     nets), "Mail" is the path to your netmail area, and "Files" is the path 
  157.     to your incoming net files area (which is what GROUP can't find if you 
  158.     only have a Mail.Sys file).  
  159.  
  160.  6) OMMM.CTL (or ROUTE.CTL or whatever you call it on your system).  Be 
  161.     sure to put a poll statement in for each system you pick up GroupMail 
  162.     from (unless you are using some other method for doing polls, or your 
  163.     feed is calling you).  
  164.  
  165.  7) DELIVER.GRP - You need this file if you are feeding GroupMail to any 
  166.     other BinkleyTerm systems, or any other system that can't generate File 
  167.     Update Requests.  Note that future versions of BinkleyTerm will 
  168.     supposedly include the capability to do File Update Requests, but 
  169.     present versions of Binkley do not.  DELIVER.GRP is simply a list of 
  170.     systems that are to receive any given GroupMail area from you.  I quote 
  171.     from SEA Technical Memorandum #0302: 
  172.  
  173.     "The GroupMail conferencing system is, by design, a pickup system 
  174.     instead of a delivery system.  If at all possible, it should be used as 
  175.     such, because that is how GroupMail avoids the bulk of the technical 
  176.     problems with echomail.  
  177.  
  178.     "However, at least one popular network mailer is not capable of 
  179.     properly negotiating a file update request, which is the mechanism by 
  180.     which GroupMail functions.  Until that can be rectified, GROUP requires 
  181.     some sort of delivery mechanism in order to link such systems into 
  182.     GroupMail.  
  183.  
  184.     "If a file named 'DELIVER.GRP' is placed in the SEAdog directory, then 
  185.     GROUP 2.03 will use it as a delivery list, and create file attach 
  186.     messages for each new GroupMail archive as it is posted by GROUP PACK 
  187.     (for a top star) or GROUP IN (by a middle star).  The format of the 
  188.     DELIVER.GRP file will look very familiar to those acquainted with 
  189.     echomail.  
  190.  
  191.     "The DELIVER.GRP file is a normal ASCII text file.  Each line begins 
  192.     with the name of a group conference, with the remainder of the line 
  193.     being a list of network addresses to which it should be delivered.  A 
  194.     conference may be listed more than once, in which case it is addative.  
  195.  
  196.     "For example, a possible DELIVER.GRP file might be: 
  197.  
  198.         BLATZ 520/1015 107/528
  199.         GNORF 107/528
  200.  
  201.  
  202.     "By adding support of a delivery mechanism, we open the door to all the 
  203.     troubles echomail is heir to.  However, the door is open only a tiny 
  204.     crack at this time.  The single biggest problem with a delivery system 
  205.     is that of faulty topologies that cause duplicate messages.  This is 
  206.     largely avoided from the start because all duplicate GroupMail archives 
  207.     have the same name.  The remaining opportunities for duplicate messages 
  208.     to be generated are avoided because GROUP 2.03 refrains from unpacking 
  209.     any GroupMail archive that is older than the 'update marker' for that 
  210.     conference." 
  211.  
  212.     [end quote] 
  213.  
  214.     Two notes about DELIVER.GRP... first, you DON'T put the node number of 
  215.     YOUR feed in it, only of those systems that are fed BY YOU (this 
  216.     differs from an AREAS.BBS file, which must contain the node number of 
  217.     your feed and of those system that you feed).  Second, if you aren't 
  218.     feeding a particular GroupMail conference to anyone else, it doesn't 
  219.     have to be listed at all.  
  220.  
  221.  8) OKFILE.LST - Your "requestable files" list for BinkleyTerm.  Add the 
  222.     following line: 
  223.  
  224.          C:\GRPHOLD\*.* 
  225.  
  226.     (or whatever path you specified for your GRPHOLD directory in the SET 
  227.     command in AUTOEXEC.BAT).  I'm assuming that you already have such a 
  228.     list.  If not, you'll also need to uncomment the following line in your 
  229.     Binkley.Cfg file: 
  230.  
  231.          Okfile     c:\opus\okfile.lst 
  232.  
  233.     (of course you should change the path if the subdirectory you're 
  234.     running Binkley out of is not called OPUS).  
  235.  
  236.     This should allow other systems to obtain any GroupMail areas that you 
  237.     carry on your system.  
  238.  
  239.  9) \GROUP\ORIGIN - A file called "Origin" that sits in your GROUP 
  240.     directory.  For starters, this can be the same as the first line of 
  241.     your "AREAS.BBS" file up to the exclamation point.  You can use custom 
  242.     origin lines for individual conferences by creating a file called 
  243.     "Origin" in individual Group areas, in the same manner in which you 
  244.     create custom origin lines for individual message areas using ConfMail.  
  245.     See the GroupMail documentation for more information.  
  246.  
  247. 10) System files.  You'll need to provide your BBS program and/or message 
  248.     reader/editor with the paths to your GroupMail areas.  Ditto with your 
  249.     message cleanup routine (that calls RENUM or some other message 
  250.     renumberer).  This will vary from system to system, but should not be 
  251.     too difficult to figure out.  
  252.  
  253. 11) GROUP.EXE - The central program of GroupMail, and the one that does 
  254.     most of the work for you.  If you've set up echomail conferences in the 
  255.     past, you'll appreciate the ease with which GROUP takes care of many of 
  256.     the little details of adding or deleting conferences for you.  For 
  257.     example, it creates all necessary subdirectories for you, creates and 
  258.     maintains the AREAS.DOG file for you, etc.  
  259.  
  260.  
  261.  
  262. Now, if you are not a Top Star, you can basically get by using only three 
  263. basic GroupMail commands (quoted from the GroupMail documentation): 
  264.  
  265. GROUP ADD <conference> <description> ;<uplink> 
  266.  
  267.      This is the command you use to add a new conference.  Suppose, for 
  268.      example, that you would like to get the BLATZ conference from 520/542.  
  269.      You would type: 
  270.  
  271.          GROUP ADD BLATZ Gzorniblatz forum ;520/542 
  272.  
  273.      GROUP will take care of the details, like creating the proper 
  274.      directories and updating your AREAS.DOG file.  If you run a BBS and 
  275.      you want the conference to be available on your system you will need 
  276.      to add the directory to your message areas.  The message directory 
  277.      that GROUP creates will (by default, see later) be a subdirectory of 
  278.      the GROUP subdirectory, or in this case it would be "GROUP\BLATZ".  
  279.  
  280.      If you are running a mailer other than SEAdog, then you may need to 
  281.      add the directory to your areas list also.  In any event, DO NOT 
  282.      delete the AREAS.DOG file, as that is used by GROUP to keep track of 
  283.      your conferences.  
  284.  
  285.      If you want to import GroupMail into a BBS that uses a different 
  286.      message base format, you'll need to do a bit more work.  See the 
  287.      section on this below.  
  288.  
  289. [You might imply from the above that you should add GroupMail areas to your 
  290. AREAS.BBS file.  That is NOT the case, however, unless you are converting a 
  291. GroupMail conference to echomail, which we're assuming that you're not 
  292. doing right now!] 
  293.  
  294.  
  295. GROUP DEL <conference> . . .  
  296.  
  297.      This is used to remove one or more conferences.  For example, if you 
  298.      wanted to remove the BLATZ conference you would type: 
  299.  
  300.          GROUP DEL BLATZ 
  301.  
  302.      If you wanted to remove both the BLATZ conference and the GNORF 
  303.      conference, you would type: 
  304.  
  305.          GROUP DEL BLATZ GNORF 
  306.  
  307.      Again, GROUP will take care of the housekeeping details, such as 
  308.      deleting any messages and removing the subdirectory.  
  309.  
  310.  
  311.  
  312. GROUP EDIT <conference> <description> ;<uplink> 
  313.  
  314.      This is used to change an existing conference.  For example, if you 
  315.      wanted to change your uplink on the BLATZ conference to 440/1, you 
  316.      would type: 
  317.  
  318.          GROUP EDIT BLATZ Gzorniblatz forum ;440/1 
  319.  
  320.      As always, GROUP takes care of any housekeeping details.  
  321.  
  322.  
  323. [end of quoted material] 
  324.  
  325. Since Binkley can't do File Update Requests, you do NOT use the GROUP ASK 
  326. command.  We've already covered the use of GROUP IN and GROUP OUT in the 
  327. batch file.  You don't use GROUP PACK unless you're a top star for a 
  328. conference.  
  329.  
  330. There are several option switches that you can use to modify how GROUP 
  331. works, and most are described in the GROUP documentation.  The one that you 
  332. will probably want to use is the /R switch: 
  333.  
  334. /R<x>  Retention;  This tells GROUP that any GroupMail archives that you 
  335.        are holding (if you are a star) should be deleted after <x> days 
  336.        (default is 30 days).  For example, you would use "/R5" to retain 
  337.        archives for five days.  
  338.  
  339. For example, if you wanted to add the BLATZ conference with yourself as a 
  340. middle star retaining GroupMail archives for three days, you would type: 
  341.  
  342.     GROUP ADD BLATZ Gzorniblatz forum ;* 520/542 /r3 
  343.  
  344. Also, because Binkley cannot generate File Update Requests, you'll want to 
  345. use the /X switch when adding new conferences, as described in SEA 
  346. Technical Memorandum #0302: 
  347.  
  348.  
  349. /X   In ADD or EDIT only.  This switch indicates that the designated 
  350.      conference should not be requested.  The GROUP ASK command will not 
  351.      generate an update request for any conference that carries this 
  352.      switch.  This is intended mainly for use with conferences which are 
  353.      delivered or which are obtained via a GROUP GET (see above).  
  354.  
  355. The bottom line is that when you add a new GroupMail conference, your GROUP 
  356. ADD line will most likely appear something like this: 
  357.  
  358.     GROUP ADD BLATZ Gzorniblatz forum ;* 520/542 /X /r7 
  359.  
  360. (assuming you want to retain conference archives for seven days in this 
  361. case).  
  362.  
  363. If you are a leaf node (that is, you don't hold a particular conference for 
  364. anyone else to pick up), omit the asterisk and the /r7 in the above line.  
  365. In this case, the GroupMail bundle will be deleted after it has been 
  366. tossed.  The command line would then look like this: 
  367.  
  368.     GROUP ADD BLATZ Gzorniblatz forum ;520/542 /X 
  369.  
  370. When you use the GROUP EDIT command, it should be in exactly the same 
  371. format as the GROUP ADD command.  In other words, if you are adding 
  372. switches, you must also re-enter all of the original switches.  The word 
  373. EDIT simply tells Group that you are modifying the particulars of an 
  374. existing conference, rather than creating a new one.  
  375.  
  376.  
  377. EXCEPTIONS AND SPECIAL CIRCUMSTANCES 
  378.  
  379. The GroupMail manual tells you how to import GroupMail into non-compatible 
  380. message base formats (such as QuickBBS or TBBS).  In this case you use the 
  381. /N flag in your GROUP ADD statement.  Since most such systems don't use 
  382. ConfMail, this type of setup is a bit beyond our discussion.  I would only 
  383. caution you to be careful about the sequence in which you run you mail 
  384. import routine and GROUP IN.  You may have to run your import routine 
  385. twice... once to toss incoming mail, then GROUP IN to toss incoming 
  386. GroupMail bundles to the netmail area (and to readdress any GroupMail 
  387. messages destined for your uplinks), and once more to import any GroupMail 
  388. messages tossed to your netmail area by GROUP.  This is just guessing on my 
  389. part, since I don't have any actual experience with such systems.  
  390.  
  391. However, a similar technique is used to convert GroupMail to Echomail.  You 
  392. might want to do this if you are receiving a GroupMail conference and want 
  393. to pass it on to another system that cannot run the GroupMail software.  
  394.  
  395. Now, I would suggest that you DON'T do this unless absolutely necessary.  
  396. If it's just a case of one of the nodes you feed objecting to having to put 
  397. up the GroupMail software (although they are perfectly capable of doing 
  398. so), I would invite them to seek a feed elsewhere.  Converting a conference 
  399. from GroupMail to Echomail introduces several possible headaches, not the 
  400. least of which is that you could be the source of duplicate messages 
  401. entering the conference.  
  402.  
  403. On the other hand, it's not something that's terribly difficult to do if 
  404. you have to.  SEA Technical Memorandum #0303 describes the process, but I 
  405. will give a couple of examples specifically for BinkleyTerm/ConfMail users.  
  406.  
  407. The assumption here is that you are a middle star that is receiving the 
  408. conference in question as GroupMail, and feeding it to some other nodes as 
  409. GroupMail while feeding still other nodes as Echomail.  
  410.  
  411. Your GROUP ADD line would be the same as usual, with the addition of the /N 
  412. switch.  For example: 
  413.  
  414.     GROUP ADD BLATZ Gzorniblatz forum ;* 520/542 /N /X /r7 
  415.  
  416. If you are not sending the conference to any other nodes AS GROUPMAIL, you 
  417. can omit the asterisk and the "/r7" switch.  
  418.  
  419. Next, you ADD this area to your AREAS.BBS file, just like you would any 
  420. normal echo.  On your system, you will treat this conference as an echomail 
  421. area rather than a GroupMail area.  The /N option that you used in your 
  422. GROUP ADD statement causes GROUP to add an "AREA:" field and a "SEEN-BY:" 
  423. field listing the address of the uplink to any conference that you're 
  424. converting to echomail.  
  425.  
  426. In your batch file, you will probably want to run ConfMail Import (WITH the 
  427. -M option), THEN Group In, and THEN a second run of ConfMail Import 
  428. (WITHOUT the -M option).  This will make sure that any GroupMail received 
  429. from your downstream nodes gets properly readdressed to your uplinks, and 
  430. that any Group conferences that GroupMail tosses to your netmail area get 
  431. properly tossed (by ConfMail) to the Echomail area you've set up for that 
  432. conference.  For example: 
  433.  
  434.      confmail import areas.bbs -M -N -F confmail.out
  435.      group in /L
  436.      confmail import areas.bbs -K -N -F confmail.out
  437.  
  438. The only other items you have to worry about are how the area is defined in 
  439. your DELIVER.GRP and AREAS.BBS files.  As usual, your DELIVER.GRP file 
  440. should contain ONLY a list of nodes receiving the conference from you AS 
  441. GROUPMAIL.  Your AREAS.BBS entry for the conference in question should 
  442. contain a list of the nodes receiving the conference from you AS ECHOMAIL, 
  443. plus YOUR FEED of the conference.  The reason for including your feed is so 
  444. that any messages entered on your system, or sent to you by your downstream 
  445. links, will be exported to your upstream feed.  
  446.  
  447. You may wonder what will happen to an echomail message sent upstream in 
  448. such a manner to your GroupMail feed.  If he is running that area strictly 
  449. as GroupMail, the message will be tossed into his netmail area (so long as 
  450. he does not have a BAD_MSGS area... this is why you CANNOT use a BAD_MSGS 
  451. area with GroupMail!!!), where (hopefully) GROUP IN will find it and 
  452. readdress it to his uplink, and so on.  If he is also operating the area as 
  453. both echomail and GroupMail, the message will get tossed into the echo area 
  454. on his system, and then exported to his upstream feed, and so on.  
  455.  
  456. Anyway, that's all there is to it... BUT again I ask, "do you REALLY want 
  457. to convert echomail to GroupMail?"  If you are only feeding one or two 
  458. nodes that cannot accept GroupMail, there may be a better way: 
  459.  
  460.  
  461. SENDING GROUPMAIL TO NON-MSDOS SYSTEMS
  462.  
  463. The following information should be considered HIGHLY experimental.  If it 
  464. works for you, GREAT!  If it doesn't, well, you can always convert your 
  465. GroupMail conferences to echomail.  
  466.  
  467. Let's say that you're feeding a point system that's running on a Commodore 
  468. Amiga (coincidentally, this is what Steve Palm, a point operator off of my 
  469. system is using).  He has a version of ConfMail and BinkleyTerm that's been 
  470. ported to the Amiga, as well as a message reader/editor, but there is no 
  471. way he can run the GroupMail software.  
  472.  
  473. But, he is a leaf node.  That means he doesn't have to worry about 
  474. forwarding the conference to anyone else.  All he needs to be able to do is 
  475. to read the messages he receives, and send replies.  
  476.  
  477. We already know (from the above discussion) that if he creates an echo area 
  478. with the same name as a GroupMail area on my system, and puts my node in 
  479. his AREAS.BBS list, that any messages he enters in that area will be 
  480. exported to my system, where GROUP IN will find them and readdress them to 
  481. my feed for the conference.  So as long as he can send me messages with the 
  482. proper AREA tag (which will be automatically affixed when ConfMail exports 
  483. the message from the echo area he's created), he will be able to enter 
  484. messages in a GroupMail conference.  So, if he can figure out some way to 
  485. process an incoming GroupMail bundle (so that he can read incoming 
  486. messages), I can just put his node in my DELIVER.GRP file and treat him 
  487. like any other GroupMail delivery point (which means I don't HAVE to 
  488. convert the GroupMail conference to Echomail!) 
  489.  
  490. The question is, can he unpack a GroupMail bundle?  Well, it turns out that 
  491. there IS a way this can be done.  Once you extract a GroupMail packet from 
  492. its archive, the extracted mail packet has roughly the same format as an 
  493. Echomail packet, except that it's addressed to -1/0.  At least, it's close 
  494. enough that ConfMail will unpack and toss it if it thinks it's running on 
  495. node -1/0 
  496.  
  497. So, in his CONFIG.DOG file, Steve inserts the address -1/0 as an AKA 
  498. address.  Then, in his batch file, he has to put a command to look for and 
  499. unARC any GroupMail bundles he might receive.  For example, if he's getting 
  500. COOKING and SHORTWAV from me, he'd put in the following lines (note these 
  501. are MS-DOS batch file lines for illustrative purposes only, not what Steve 
  502. is actually using on his Amiga): 
  503.  
  504.      ARCE \FILE\NET\COOKING.*
  505.      DEL \FILE\NET\COOKING.*
  506.      ARCE \FILE\NET\SHORTWAV.*
  507.      DEL \FILE\NET\SHORTWAV.*
  508.      CONFMAIL IMPORT AREAS.BBS -N -A ARCE 
  509.  
  510. ConfMail will find the bundles (addressed to -1/0, but the AKA takes care 
  511. of that) and unpack them.  Next... and this is important... he must do a 
  512. CONFMAIL EXPORT using an alternate AREAS.BBS format file that contains the 
  513. following: 
  514.  
  515.      Origin Line ! Sysop Name
  516.      \MSG\COOKING COOKING -1/0
  517.      \MSG\SHORTWAV SHORTWAV -1/0
  518.  
  519. Why are we exporting to -1/0?  Well, since GroupMail uses that address, I 
  520. thought I would, too... actually, we could export to ANY phony node, but 
  521. the idea is to make ConfMail do an export operation on the newly-imported 
  522. GroupMail messages.  Why?  Well, keep in mind that GroupMail messages don't 
  523. have an origin or SEEN-BY lines.  Thus, if we simply allow them to be 
  524. rescanned in the normal manner, we've created an instant dupe loop, since 
  525. they will all get sent back to the source.  So, we do a "dummy" export 
  526. operation in order to reset the "high water mark" past the last new message 
  527. that we have just received in the area.  This may create an unwanted ".OUT" 
  528. file for -1/0, but we can always delete that as the next operation in the 
  529. batch file 
  530.  
  531. So, the complete batch file segment would look something like this: 
  532.  
  533.      ARCE \FILE\NET\COOKING.*
  534.      DEL \FILE\NET\COOKING.*
  535.      ARCE \FILE\NET\SHORTWAV.*
  536.      DEL \FILE\NET\SHORTWAV.*
  537.      CONFMAIL IMPORT AREAS.BBS -N -A ARCE
  538.      CONFMAIL EXPORT ALTAREAS.BBS {options}
  539.      DEL \OUTBOUND\FFFF0000.OUT
  540.  
  541. where ALTAREAS.BBS is the alternate AREAS.BBS with the dummy -1/0 net/node 
  542. numbers, and FFFF0000.OUT is the name of the mail packet (for -1/0) created 
  543. by the dummy export operation.  
  544.  
  545. Of course, when messages are entered using the message reader/editor, we 
  546. have to run ConfMail Export using the "real" AREAS.BBS file that contains 
  547. the same entries, but with the real net/node numbers for the GroupMail 
  548. feed(s) from which the conferences are received: 
  549.  
  550.      Origin Line ! Sysop Name
  551.      \MSG\COOKING COOKING 154/8
  552.      \MSG\SHORTWAV SHORTWAV 154/8
  553.  
  554. Now, all of the above will work BUT there is one MAJOR problem.  It turns 
  555. out that while each GroupMail bundle has a unique filename, two or more 
  556. GroupMail bundles for the same conference can contain .PKT files that have 
  557. exactly the SAME names.  Thus, there is a very good chance that the above 
  558. batch file segment would fail whenever more than one mail bundle is 
  559. received for the SAME GroupMail area in the same transmission (it would 
  560. most likely stop and ask the user whether to overwrite the the .PKT file 
  561. from the first mail bundle with the .PKT file from the second... or on some 
  562. systems, it might just go ahead and overwrite the file without asking, an 
  563. even less desirable situation!).  On an MSDOS machine, you could use a FOR-
  564. DO loop in the batch file to unarc each GroupMail bundle and then have 
  565. ConfMail toss (import) the contents of that mail bundle before unarcing and 
  566. tossing the next GroupMail bundle (but then, on an MSDOS machine you could 
  567. just run the GroupMail software).  There are probably ways to accomplish 
  568. the same thing on other systems, but the actual method would depend on the 
  569. commands available in the batch file language, and/or the availability of 
  570. external utilities that might aid in the process.  Or, you could just run 
  571. the batch file manually (when an operator is present to watch and resolve 
  572. any such conflicts that might occur)... that might be the most expiditious 
  573. method at present for point system operators.  Note to the developers of 
  574. GroupMail:  It would sure be nice if future versions did not create 
  575. duplicate .PKT names within different mail bundles for the same GroupMail 
  576. conference.  
  577.  
  578. The method I've shown for preventing the imported GroupMail messages from 
  579. being rescanned back to the GroupMail feed is not real elegant, and begs 
  580. for a simple utility that would either a) reset the "high water mark" (the 
  581. number of the last message scanned by ConfMail Export) to that of the 
  582. highest message in the area, or b) append an Origin line and SEEN-BY lines 
  583. to any messages that don't already have them in the specified area, and 
  584. place the net/node number of the feed for the area in all messages 
  585. currently in that area.  Such a utility could be run every time messages 
  586. have been tossed to the specified area, and would eliminate the need for 
  587. the dummy ConfMail Export operation.  Yet another (better) option would be 
  588. to forget the alternate AREAS.BBS file and the dummy ConfMail Export 
  589. option, but instead use only the regular AREAS.BBS file with NO net/node 
  590. number following the Group conference area names, so that messages in Group 
  591. areas would NEVER be exported by ConfMail.  Then use a separate utility 
  592. that would search through Group conference areas for locally-originated 
  593. messages (messages containing the node's primary net/node number in the 
  594. FROM field of the message header) and move those TO the netmail area, at 
  595. the same time readdressing them to the feed for the GroupMail conference 
  596. and flagging them as Kill/Sent.  Such a utility would be relatively easy to 
  597. create, and would allow non-MSDOS systems to handle GroupMail in a way that 
  598. more closely resembles the way GroupMail is supposed to operate (that is, a 
  599. locally-entered message disappears from your BBS until such time as it 
  600. comes back as part of a GroupMail packet).  
  601.  
  602. But, at this point, the fact that a non-MSDOS system can import and process 
  603. GroupMail is a bit akin to the dancing bear... the wonder is not how well 
  604. it's done, but that it can be done at all.  
  605.  
  606. I hope that these hints prove helpful to you in setting up GroupMail on 
  607. BinkleyTerm/ConfMail and other types of systems.  Please let me know if you 
  608. find any glaring errors in the above information, or if you can add 
  609. anything that might simplify the process or make it more understandable.  
  610.